Name: SMDIPROT 
Description: 


Document Version: 


orporation 


© 199] Peavey Electronics Corp. 1 Version 0.03 SMDIPROT March 1992 


Contents 


SCSI Musical Data Interchange Protocol (SMDI) ou. eden 3 
COME VIC W a3 cede St eae sade ead Sa doa cedecdiaadsced dass saad eeddeedaseegecheendacs sestedaadiuadds le eiscnasueetieads ae 5 
SCSI. Backoround 3.2.2.2 cece no eae aa ee ae ncaa ee ae 4 
General Principles of SMDI Messages and Transactions .............eeeeeeeeeeee! Gh a sssvehevoons sake  cseass 5 
SMDI Message and Transaction Errors ............essseeeeessneeeeeeeseeeeeeeeaes Poin CENT ccc eeccceeeeseeees A 


SMDI Procedures : i eee 9 


SMD Capability Test.vcuiaxnidetuicelig aia ealenee ds ce 10 
Obtaining A Slave Sample Header.............ccccececeeeeeeeeeeeeeeeee dite eeeeeeeees eas cs sesac ea enna boawoeeoennen 10 
Transferring A Sample From Slave To Master.............eeeeeeeee bts ha ates sd ede oueede ene 11 
Transferring A Sample From Master To Slave ...........eeeeeeeeeeeee ee CORRES cece cece ececseeeeeeeeeeeeeeeenaaeees 12 
Deleting A Sample From Slave Memoty .............:::.e08 Bessel Ain ieee oe ed eee eine ee 14 
SIVIDIIMGSSAB ES: 5. astiiasinsusstatutasaowmtsaantnautas SE ERD Oe COT CCR POC eT ery 14 


© 199] Peavey Electronics Corp. 2 Version 0.03 SMDIPROT March 1992 


SCSI Musical Data Interchange Protocol (SMDI) 


Overview 


St 


: -compared to MIDI. The sample transfer 
yhile remedying some of its specific 


protocol goes beyond the limitations which MIDI SDS i 
deficiencies. ‘ 


SMDIis not intended as a general-purpose in ‘interchange platform. However, ample room 
is available for the definition of new messages 
addition to the actual sample transfer protocol, 
via SMDI, and sets aside certain message ¢& 
This allows SMDI to fully support appli. 


ete 
Tre 


rovides a convenient path for the migration of existing MIDI data- 


#Odification, as well as a means whereby a single application can 
the communications interface. 


It may be worthwhile: nit be: two more things SMDIis not: 1) an attempt to find a successor to MIDI 


- SMDI, and SCSTin ge 
= typesefreal-time event communication for which MIDI is commonly used, and 2) an 
or MIDI network - SMDI addresses the data-transfer aspects of digital audio and 
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SCSI Background 


SMDI employs a limited set of SCSI commands available to devices which conform to the standard 
SCSI definition for a processor device. Processor devices communicate by transferring data packets using the 


SCSI SEND and RECEIVE commands, which are defined only forthe SCSI processor device typgz, The SEND 


fiikes the SEND 
[messages as SEND/ 


in and message-out), which are not utilized by SMDI. 


The specification for a SCSI processor device includeg 
commands in addition to SEND and RECEIVE. Notable among 


sire 


and REQUEST SENSE, all of which are utilized by SMDI certain times. The INQUIRY command 
is the one whereby target device identity information iso 5 # significantly the SCSI device type 
which should be 03h for SMDI slave devices, indicating SCSI processor devices which implement 


the SEND and RECEIVE commands. A SMDI maste# Hot issue these commands to any target device 
sng eee SMDI provides additional means 


READY and REQUEST SENSE are ett 
slave devices must be able to sooty) 1 


Sctions. As with any SCSI target mode device, SMDI 
f’ reject unrecognized SCSI commands without causing 


d in a music environment usually do not readily support SCSI 
tire burden of conducting communications in both directions upon 


Sree 
es 


entréned that there is no prohibition against a single device being able to assume both 
MDI slave roles at different times, provided that it maintains any given role for the duration 
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General Principles of SMDI Messages and Transactions 


This section contains a significant amount of detail pertaining to SMDI at the level of an individual 
message and its component parts, as well as some discussion of the rationale behind the design of the message 
format, and of conditions which are considered a as errors. The reader may find it helpful at first taiead quickly 


ist entirely of sequenced 
exchanges of such messages. SCSI commands other than SEND and & e not usually involved in 


SMDI procedures. 


The SEND and RECEIVE commands, in and of themselve "40 not convey any SMDI information and 

ee emmands are quite generic, in essence 
4d or the maximum data packet length 
which an initiator is prepared to receive. (In SCSI, , this maximum length is referred to as 
Allocation Length. A SCSI target device can legally ote amber of bytes up to the specified Allocation 


Length without violating SCSI rules, although, 
more, when it is not limited by the Alloé 
RECEIVE command alone to request any, 


Xt message which will be sent to it by a SMDI master device, 
pn such a procedure. Finally, any SMDI device is likely to be called 


The full meaning of each of these principles, and their implications, are elaborated upon in the 
following discussion. 


All SMDI messages fully identify themselves via their message content. Every SMDI message begins 
with a SMDI message header which is followed by additional bytes as appropriate to the particular message. 
Some SMDI messages consist only of a header. The SMDI message header is always 11 bytes long and consists 
of three distinct parts, presented here in order of appearance: 


1. The SMDI message tag is a fixed four-byte string (“SMDI’) serving as an identifying tag for all 
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SMDI messages. 
2. The Message Code identifies the type of message. It consists of a two-byte Message ID code, 
followed by a two-byte Message Sub-ID code. 
3. The Additional Message Length is a three-byte field which indicates the number of bytes 
following the header in the current message. 


RECEIVE data packets which are SMDI messages and those which are not. SEND/] 
not beginning with this tag are not to be recognized as SMDI messages, and should 


with a specific length value for a message being received f ito assist it in correctly completing the 
SCSI RECEIVE command. Without this parameter, th as no direct indication of the actual 
length of an incoming message. Although most SMDE: ave a fixed length which is implied by the 
Message Code, there are some messages whose leng vary. More importantly, the inclusion of the 


‘ice to correctly complete a RECEIVE command 
turned, thereby making it unnecessary for the master 
to have specific knowledge of each and 
unanticipated future extensions to the M 


As used ina messagé A 
since it should always be \eSEND command Transfer Length minus eleven (the size of the SMDI 
evél, it serves as a further message integrity indicator. Slave devices which 
+numbers should always defer to the SCSI Transfer Length value in order to 
. Master devices should also perform such an integrity check when receiving 


til Hy those which have a fixed length, and should consider conflicts as cause for 


AlSMDI transactions consist of aSEND followed by aRECEIVE. A SMDI master issues a RECEIVE 
command in order to obtain the slave’s response to the most recent SEND command (referred to as a “‘reply”’). 
The message which a SMDI slave presents during a RECEIVE command is always its reply to the message 
sent via the most recent SEND command. This alternation must be adhered to strictly, with only rare 
exceptions. Deviations, which include spurious RECEIVE commands not preceded by a SEND, as well as 
SEND commands issued to a slave device which is still holding the reply to a previous SEND command, are 
flagged as SCSI errors. The slave device thus enforces the SEND/RECEIVE alternation by refusing to accept 
SEND and RECEIVE commands which are issued out of sequence. 


SMDI messages must always be transmitted in their entirety. In order to successfully receive a slave 
message, a SMDI master must issue its RECEIVE command with an Allocation Length adequate to fully 
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receive the message which the slave wishes to return. Although the master cannot predict with absolute 
certainty the message which it will receive, the number of appropriate slave replies to any given message from 
a master device is usually very small - the master should set its Allocation Length to accommodate the largest 
of the anticipated messages. 


The slave device is always required to return its entire message if the presented Alldgistax fr 
large enough to permit this. However, the slave device is not permitted to exceed thg 
limitation set by the RECEIVE command. If presented with an inadequate Allocation 


retain its reply (message) in anticipation of a subsequent attempt by the master tq..cot problem and 


receive the complete message. In contrast to the usual handling of Allocation L ands such as 
INQUIRY and REQUEST SENSE, where a target is expected to return byte cation Length limit 
if this is smaller than the total number of bytes available, a SMDI slave 6n is expected to return 


As well-behaved SCSI target devices, SMDI slave devidgs are required to correctly complete any 
31 rules. The SEND command Transfer 


{arise is appropriate only under very exceptional 
ded bytes may represent a valid SMDI message 
ime that it appears (this would be reported as aSMDI 


operation, wh; 
to detect su 


See 


‘ind respond to them in a consistent manner. Most of this burden falls to the slave 
geport all errors back to the master. The master should be able to detect errors in messages 
e appropriate action, but this action does not include reporting of errors to the slave. 


SMDferror conditions fall into two main categories: those which are reportable using SMDI messages, 
and those which require SCSI-level handling. SMDI strives to keep communication at the SMDI level as far 
as possible, using only normally-terminated SEND and RECEIVE commands at all times. SCSI-level error 
handling and reporting (i.e., CHECK CONDITION status and the use of the REQUEST SENSE command) 
is considerably more disruptive and is employed only where the use of SMDI messages is made impossible 
by the circumstances of an error, or where the error condition is clearly outside the proper domain of SMDI. 


Errors in the first category are related to valid SMDI message exchanges in which the message content 
is at issue - for example, the sending of a message with an unrecognized Message Code to a slave, or one which 
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is inappropriate in the context of a SMDI procedure currently in progress, or which contains an unexpected, 
incorrect or inappropriate parameter value in some part of the message beyond the message header. SMDI 
provides the means for a slave to report all such errors at the SMDI message level. 

Errors in the second category are typically related to incorrect SEND/RECEIVE sequencing, or to 
problems i in the SMDI message header itself. Such errors do not normally arise when properlys eats 


a REQUEST SENSE command and read extended sense data in order to obtai. 
oo the error. Within this category are two classes of errors: those yi 


parameter in the SMDI message header is in conflict wit 
command, and those in which the Additional Message Leng 


sfer Length parameter of the SEND 
ey ar deviates from the expected value for 


typically, discard) bytes from the initiator until the da Ol aSe is complete, based upon the value of the 
Transfer Length parameter of the SEND compan A 
phase. = 


Errors in the second class are detectat# 
SEND/RECEIVE sequencing or to un, 


phase to status phase to rep on F 


eply*sath, and to retain this message as a pending reply. The header should indicate the 
Additional M * Length as though the entire message was being returned - this is referred to as a truncated 
receive, and provrég-the master with the information it needs to allow the complete message to be received 
without a violation of SCSI rules. The slave, in this situation, does not explicitly signal an error condition in 


either the SCSI or SMDI domain. 


The master device is expected to detect a truncated receive when it occurs by noting that the Allocation 
Length which it used was not sufficient to accommodate a message with a length as indicated in the returned 
header, and is expected to immediately (i.e., without an intervening SEND command) make another attempt 
to receive the pending reply, using a larger Allocation Length based upon the Additional Message Length value 
in the returned header. Note that this is an exception to the SEND/RECEIVE alternation rule, as well as to the 
usual definition of the Additional Message Length parameter (since no additional message bytes will follow 
in this case). As is true at any other time when a SMDI slave has a reply message pending, the reply will remain 
pending until it can be completely transferred to the master, and any SEND command issued during this time 
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will be rejected. 


Because the SMDfTerror conditions which are reported using SCSI-level error handling are nonetheless 
unique to SMDI, the sense data which a SMDI slave will return in response to the REQUEST SENSE command 
after such an error will consist of codes in the vendor-specific code ranges. The sense key will be 09h, the catch- 
all sense key for vendor-specific errors. The additional sense codes should also be read, as thesé%ill indicate 
precisely which SMDI error occurred (see table xxxx). SMDI devices should not use the SCS. : 


sense data format. SMDI slaves should be capable of returning the mandatory (SCSI 2) m 


REQUEST SENSE command. 


SMDI Procedures 


ASMDI procedure consists of one or more interlocked cae, 
between a SMDI master and a SMDI slave. 


SMDI procedures provide the master device with the, 


memory or directing the slave to save its mem ¥ COHfagts to its own mass storage, if appropriate procedures 
have been defined. Other standard proced V j 
preliminary version of the SMDI protocol, f some using messages which also will be defined at a later 
time. Manufacturer-specific proces oud ‘sible, provided that they adhere to all of the protocol rules. 


Both single- and a : sedures follow prescribed sequences which allow for little or no 
ripsementing these procedures in software a fairly simple one. There is 


and the appearance of anyiiiw oipriate or unexpected message is always considered cause for immediate 
termination of the proces 


when it appears. A SMDI slave uses this message to terminate a procedure if the master sends it an 
inappropriate message (a slave must never abandon an incomplete procedure without completing the last 
SEND/RECEIVE exchange). 


Most other SMDI messages have very specific uses and are considered inappropriate outside of their 
limited areas of applicability. While in the idle state, a SMDI slave is expected to reject any message from a 


master which is not appropriate to the idle state - i.e., which is not a message used to initiate a procedure. 


The SCSI commands TEST UNIT READY, INQUIRY and REQUEST SENSE are not components 
of SMDI procedures. SMDI slave devices should be able to field these commands at any time without effect 
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upon a SMDI procedure in progress, including during the interval between a SEND command and its 
corresponding RECEIVE command. However, when a procedure is in progress, it is acceptable for a SMDI 
slave to terminate these commands with BUSY status instead of responding normally. 


A reading of the following procedures should make clear the ee for confusigg and errors 


against this by keeping track of the SCSI ID of the master device with which it is communsé 
of the SCSI ID information presented during the selection phase. When a multi-exchang 


phase, the slave must assume a single-initiator system with the initiator on SCSE# 


SMDI Capability Test 


The master sends an SMDI Master Identify messags 
Identify message. This procedure should be performed 
processor device using the INQUIRY command, and 
must send no further SMDI messages to this target 
restrictions on the use of this procedure when SI 


t ehh ae ‘thet SMDI procedures. The master 
sto reply properly to this one. There are no 
are in an idle state. It is permissible to use this 


This procedure is usé = # f8fep when the master wishes to select a particular sample in the slave 
for transfer to the master, or js. (fits own when the master merely wishes to obtain information about the 


ple Header Request message to the slave, then expects to receive either a 
“ar a SMDI Message Reject message as reply. The master must use an Allocation 


The Sample Header reply is used if the specified sample exists and if it can be transmitted to the master 
if requested. The Sample Header is analogous toa MIDI SDS dump header - it presents all relevant information 
about the sample. If the master is preparing to obtain this sample from the slave, the Sample Header provides 
the information which allows the master to decide whether or not it can actually accommodate the sample. 


The SMDI Message Reject reply is used if the specified sample does not exist, including cases in which 
the specified sample number is beyond the range used by the slave device. A SMDI Message Reject reply 
should also be used if the slave device’s normal capabilities do not include the transfer of sample information 
to another device. 

The slave device must not assume the liberty of interpreting sample numbers in a loose or inconsistent 
fashion. While the slave can use any desired method to map SMDI sample numbers to its own internal wave 


© 199] Peavey Electronics Corp. 10 Version 0.03 SMDIPROT March 1992 


numbers, this mapping must always yield the same result for a given SMDI sample number (i.e., it must always 
point to the same sample location in the slave regardless of circumstances such as addition/deletion of other 
samples, etc). Furthermore, the mapping must be unique - it must not permit more than one SMDI sample 
number to point to a given sample location. Sample numbers should not be aliased by the slave. 


Transferring A Sample From Slave To Master 


The master executes the procedure for obtaining a slave Sample Header. This pee 
confirmation that the sample exists and can be transferred to the master, as wella 
the master needs to determine whether it can n accommodate the ae and mee 


The master must receive a reply from the 
SMDI Message Reject. 


Packet Length it is able tetsit#ipor punder no circumstances should the slave specify a Data Packet Length 
larger than the maximu : : 


Transfer message. A SMDI Message Reject reply should also be used if the slave device’s normal capabilities 
do not include the transfer of sample information to another device. 


Assuming that the Begin Sample Transfer Acknowledge reply has been given, the transfer now 
proceeds as a series of slave-to-master packet transfer exchanges, each of which is as follows: 


The master sends a Send Next Packet message to the slave. This message includes the number of the 
packet currently expected. 
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The master must then receive a reply from the slave. The reply is either a Data Packet message, aSMDI 
Message Reject message, or an Abort Procedure message. 


Note: That the master, when receiving the reply, must use an Allocation Length which is large enough to 
accommodate a complete Data Packet message (usually much larger than the other posgible 


ee 


replies) in order to ensure that the entire reply will be received from the slave. This ie 
to the Data Packet Length plus the Data Packet message overhead (SMDI sas ; 
Packet Number). : 


is equal 
#plus 


The Data Packet reply is the expected one. 


he te 


The SMDI Message Reject reply is used when the Packet Numer thes # S Send Next Packet 


Ems nuat® 
émaster sends an Abort Procedure message 
slave replies to the Abort Procedure message 


not be used under normal conditions. 


Following the successful completioré ‘Data Packet exchange, the master is expected to initiate 
the next packet exchange. Each Data Pag 
the slave indicated would be used for thi 
number of bytes remaining ie t 
point a final Data Packet which’ 
others) is transferred. The it : 
appearance of the final Dat, t rites sage and its data ‘length. Once the final Data Packet is transferred, the 


ot 
LN ey 


The master sends a Sample Header message to the slave. This provides the slave with all of the sample 
information which it needs to determine whether it can accommodate the sample, and which it will use both 
to enact the transfer and to maintain the sample after it has been transferred. The master must receive a reply 
from the slave which will be either Begin Sample Transfer Acknowledge or SMDI Message Reject. 


The Begin Sample Transfer Acknowledge reply is given to indicate that the slave is able to accept a 
transfer of the indicated sample from the master, and that it is ready for the master to initiate the transfer. This 
reply also informs the master of the maximum Data Packet Length which can be accommodated by the slave 
for the current transfer. 
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The SMDI Message Reject reply indicates that the slave cannot currently accept a transfer of the sample 
as it was represented by the Sample Header. Possible reasons for rejection include insufficient memory space 
available or a sample number which is beyond the slave device’s range. A slave which can accommodate only 
monaural cee data files may reject a Sample Header indicating multiple anler ea ed channels of sampled 


to sample numbers other than the one specified by the master# 
order to ensure that the master will have the assumed high deg 
memory. 


rh 
ep 


receive a reply from the slave which 


‘the series of master-to-slave Data Packet transfer 
Data Packet message by the master, followed by the 


Send Next Packet is the expected reply 
exchanges. Each exchange consists of th 


Reject. 


Wait is given as a reply w, heve the ves iS unable to immediately accept the next Data Packet. 
Typically, the reason for t s 
location before it can begin tra 
waiting, the slave device s§ 


srs 


e fiiaster device must issue the TEST UNIT READY command periodically 
to the slave until it regp Gis" with READY/GOOD status. The frequency of issue of these commands is left 
device, but should not be less than once per second in order to avoid excessive 
EADY/GOOD response from the slave, the master must receive a reply from the 


Note: That this is an TeeRoe pun to the SEND/RECEIVE alternation rule. The master should then resume 
the Data Packet exchange process. If the slave is not able to maintain normal SCSI communica- 
tions during the time it is busy, it can simply go completely off-line until it is able to resume the 
transfer. 


A SMDI Message Reject reply may be obtained in response to the Begin Sample Transfer message if 
the sample number in this message is different from the one which was contained in the preceding Sample 
Header message, or if no Sample Header message was sent by the master immediately prior to the Begin 
Sample Transfer message. During the packet exchange process, a reject reply will be obtained if the Packet 
Number contained in a Data Packet is different from the packet number expected by the slave at that point. A 
SMDI Message Reject reply may also be obtained if the slave device’s normal capabilities do not include 
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accepting sample information from another device, although if such is the case, the slave device will most 
likely reject the preceding Sample Header message and thereby prevent the procedure from proceeding any 
further. 


Data Packet exchanges proceed in a manner similar to those in the procedure for transferring a sample 
from a slave to a master. After accepting the final Data Packet from the master, the slave should ply with an 
End Of Procedure message, at which point the procedure is complete, and both mas 


disengaged. 


delays on the part of the slave, the slave mé 
exactly the same fashion as was described'#f 
and the End Of Procedure reply is expectg 


CCC 


ee 


ire for transferring a sample from a master to a slave, 
ait period ends. 


Command#escriptor Blocks (CDBs) for the SCSI SEND and RECEIVE commands used to transmit 
SMDI messages are shown immediately below for reference. For the purposes of SMDI, all fields in these 
CDBs other than the operation code (byte 0) and the Transfer/Allocation Length (bytes 2-4) should always be 
set to zero. A slave device which receives these commands with non-zero values in bytes 1 or 5 is required to 


reject them according to the standard SCSI method for responding to an Illegal Request condition. 


Each message diagram indicates only the actual message text - 1.e., the data transferred during the the 
data-out phase of aSEND command or the data-in phase of a RECEIVE command. The command descriptor 
block for the associated SCSISEND or RECEIVE command is not shown with each message description, since 
it is always the same except for the Transfer/Allocation Length value. 
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SMDI Message: No Message 


D Code (OO00H) 


(LSB 
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SMDI Message: SMDI Master Identify 
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SMDI Message: SMDI Slave Identify 
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SMDI Message: SMDI Message Reject 


i 
ot 
Pe 
Bh, 


ection Code 


Slave reply to a any message from a master requesting information which is not available or an 
operation which the slave is not able to perform, or containing invalid or out-of-range parameters, or arriving 
at an inappropriate time, or otherwise presenting a situation in which the slave cannot provide the reply 
normally expected. The Message Reject message contains specific rejection codes which indicate the reason 
for its use as a reply. Defined rejection codes are listed elsewhere in this document. 
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SMDI Message: ACK 


of a procedure - e.g., A 
exchange. 
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SMDI Message: NAK 


ode (OOOOH) 


(LSB 
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——- Ts — 


bet : reply a slave at any time during a procedure to notify the master that 
an abnormally long or unj will be experienced before the procedure can continue. This is typically 


related to a need on the 


to continue the “éxample, deleting a sample from memory when the master is sending a new one 
to the same Wait message is appropriate whenever the anticipated delay has some likelihood 
of approachi andard 250 millisecond SCSI Selection Response Time and thereby raising the possibility 


The Wait message is never an expected reply, but always preempts a different expected reply. At the 
end of the delay signalled by the Wait message, during which the slave device may or may not go completely 
off-line, the slave is expected to have areply message pending for the master, which receives the pending reply 
in order to resume the procedure. The master must not attempt to send any further messages to the slave before 
it has received this reply. The message with which the slave replies at this time depends upon the procedure 
being performed, as well as upon current device conditions. Typically, however, it will be the reply which was 
originally expected at the time that the Wait message was received in its place. In this sense, the Wait message 
and its associated delay can be viewed, from a procedure perspective, as having been inserted transparently 
between a message SEND from a master and its RECEIVE of an expected reply. 
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SMDI Message: Send Next Packet 


12 


— 
Oo 


transfers - received from the slave during master-to-slave transfers. The Packet Number is that of the next 
packet to be sent. 
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SMDI Message: End of Procedure 


May be used by slave oi aster to signal or acknowledge the normal completion of a procedure. The 
uses of this message are gti é 
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SMDI Message: Abort Procedure 


faster or slave at any time during any procedure to halt the procedure 
‘by the master, the slave should reply with an Ack message to complete 
its acceptance of the Abort Procedure message. 


immediately. If this me 
the message exchange, 
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SMDI Message: Data Packet 


a 
chs 
ee 
We 


rhe 


This message is used to transfer a packet of data in either direction between master and slave. The 
content of the data section of the Data Packet message depends upon the particular transfer currently in 
progress. It may be raw sample data, device-specific control information, or any other type of information 
which, because of its nature, is more convenient to transmit as a series of packets than by way of specific 
messages defined for that type of data. The Data Packet message format shown above is used in all cases. 
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Raw sample data transfers use a data format identical to the Sound Designer II data-fork format. Each 
packet contains anumber of sample data words represented as a string of bytes. Sample data is encoded intwo’s 
complement format. 16-bit sample data is sent two bytes per word in little endian format - i.e., MS byte first, 
followed by LS byte. Data of other precision is handled by adjusting the format accordingly. Two bytes per 
word are used for samples with resolution from 9-15 bits, with the ca bits of each sample, i eft- -justified 


of 8-bit or lower resolution require only a single byte per sample: with ails data again leféfirst 2 din each 
byte. Samples with resolution beyond 16 bits require three or more bytes per sample word 2h : 
rule applies here as well. 


The data byte count of a Data Packet message may not be such as to sp mple data word 
across consecutive packets. The data byte count of a Data Packet message must ; #610. There is no other 
specific lower limit on the allowable size of a Data Packet except for & Be tic satisfy requirements (such 
as the one regarding word-splitting) imposed by the packet contents. % : 


Multi-channel sounds are transmitted in an interleaved format of asétiding channel number according 
to the number of channels involved. For example, a stereo samplég sent as alternating left and right sample 


vith packet number 0 and proceed through packet 
1, 2,3, ...,n-1. The total number of packetgixe smplete any transfer is determined completely by the 
size of the file being transferred, the data fo 
expected to be the same length, with th 
others, since it contains only the bytes.x 


end of the final packet. 
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SMDI Message: Sample Header Request 


Es a De 
Byte : 


with Message Reject The sample number is used to indicate a specific sample location in the slave device 
about which the master wishes to obtain information. 
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SMDI stan —— a 


Sample format - Bits Per Word 


Sample format - Number Of Chann« 
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— 
ON 


Sample Period (nanoseconds) 


ee 
poecnpecopocces 


Sey 


a | 
tee 
pd 


at 


a 
ae an 
ae) 
: 


Sample Name (n bytes) 


> 
+ 
Oo 
fo 


The sample header message transmits essential sample control information. 
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In general, parameters are as per the MIDISDS Sample Dump Header. however, that multi-byte values 
are transmitted in MS-byte-to-LS-byte order, in contrast to MIDI SDS, but in keeping with general SCSI 
practice. 


audio channels into a single file. This follows the Sound Designer II method of sam 
more than one channel of sample data is indicated, the Sample Length, Loop Start and F d anes aval 


ie: 


resenteg fy the sample when played 


Sample Pitch indicates the absolute musical pitch of the sound & 
at the specified sample rate. Iti is presented in an eae for 


The length of the string may, 
parameter. ne 


stetoty 


Sample Header message containing a name string may alter the received 
e above restrictions or, more importantly, to meet constraints imposed by 
y on the length of the name string). If appropriate, the sample name may be 
Staple Header message should never be rejected on the basis of the Sample Name 


A device which # 


which is relayed to noice device may be altered to some bdeviee upon arriving there. If the device generating 
the Sample Header message does not maintain name information, or does not have name information for the 
specified sample, it may specify a Sample Name Length of zero, and omit the Sample Name string entirely. 
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SMDI Message: Sample Name 


pel  k 
Byte 
0 


fs 
ee 
at 


The Sampéep 
a slave device. Comments regarding the Sample Name parameter are the same as those for the Sample Name 
portions of the Sample Header message - refer to the description of that message for further details. 


The expected reply is End Of Procedure. The Sample Name message should be rejected only if the 
specified Sample Number is out of range or corresponds to an unused sample location in the slave, or if the 
slave does not support this operation. 
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SMDI Message: Delete Sample From Memory 
] 


SMDI message tag (“SME , 


ts 
page 
Ee 
ae 


Message ID Cod 


i 


ee 


tt 
ee 


2 mple Number 


Used by a figagter device to command a slave to delete a specific sample from its memory. The expected 
reply is End Of Procedure - a Wait reply and associated delay may be inserted ahead of this reply. The Delete 
Sample From Memory message should be rejected only if the specified Sample Number is out of range or 


corresponds to an unused sample location in the slave, or if the slave does not support this operation. 


© 199] Peavey Electronics Corp. 32 Version 0.03 SMDIPROT March 1992 


SMDI ro ti —— T — 


Used in conjunction with Begin Sample Transfer Acknowledge (see below). 
Sent by a master to a slave to initiate the transfer of a sample in either direction. Assumes that a sample 


header has been successfully transferred in the immediately-preceding message exchange. The Sample 
Number must match that of the preceding Sample Header message. A slave should reject this message if either 
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of these conditions is not met. 


In transfers from slave to master, the Data Packet Length value specifies the maximum Data Packet 
length (in bytes) that the master can accommodate. The expected slave reply is Begin Sample Transfer 
Acknowledge. 


In transfers from master to slave, the Data Packet Length value specifies the Data 
bytes) that the master will use. The expected slave reply is Send Next Packet. 
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oes i aha se T es is Acknowlea 


Used in conjunction with Begin Sample Transfer (see above). 


Received froma slave as a reply to amaster’s Begin Sample Transfer message when initiating a sample 
transfer from slave to master. In this case, the Data Packet Length value indicates the number of data bytes per 
Data Packet message that will be used by the slave in carrying out the transfer. 
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Received from a slave as areply to a master’s Sample Header message when initiating a sample transfer 
from master to slave. In this case, the Data Packet Length value indicates the maximum number of data bytes 
per Data Packet message that can be accommodated by the slave in carrying out the transfer. 
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SMDI an Transmit MIDI a 


Message ID Code® 


e 3 


cee 


ID " 4 


interface. The string should contain one and only one complete MIDI message. The SMDI protocol does not 
support MIDI running status - status bytes must be presented explicitly. 


The use of SMDI for MIDI message transmission is mainly envisioned as a method of transferring 
system exclusive and other non-real-time information. SMDI is not appropriate for transmission of time- 
critical performance or timing event messages. Nonetheless, there is no prohibition against using SMDI to 
transmit such MIDI event messages if the inherent limitations of doing so are not objectionable (e.g., 
transmission of test note events from within sample editor/librarian applications). 
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Also, SMDI capability does not imply any specific type or degree of MIDI implementation, nor does 
it define SMDI slave replies to MIDI messages transmitted by a master using this protocol, other than a default 
reply of No Message to a MIDI message sent by a master device. This may often be the most appropriate reply 
to such a message. more specific replies, such as MIDI messages returned by the slave, are also possible, but 
are not defined by the SMDI protocol. 
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Table 1 - SMDI Message Codes 


Note: Message ID Codes FOOOH-FFFFH are reserved for manufacturer or device specific messages. 


0000H 
0001H 
0001H 
0002H 


0100H 
0101H 
0102H 
0103H 
0104H 
0105H 


0110H 


: "Sample Header Request 

Sample Header 

Begin Sample Transfer 

Begin Sample Transfer Acknowledge 
Sample Name 

Delete Sample From Memory 


0120H 
0121H 
0122H 
0122H 
0123H 
0124H 


0200H Transmit MIDI Message 
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Table 2 - SMDI Message Rejection Codes 


Message Rejection Code Message Rejection Sub-Code niESSe 


Rejection Cause 


0002H 


0005H 


0011H 


0020H 


0022H 
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0002H 


40 


Request or other sample operation 
message rejected: 

- Sample Number is out of range 

- no sample at this Sample Number 

- insufficient sample memory available 
- insufficient param memory available 
- can’t accommodate Sample Format - 
Bits Per Word 

- can’t accommodate Sample Format - 
Number Of Channels 


Begin Sample Transfer message 
rejected: 


- Sample Number does not match that 
of previously transferred Sample 
Header 

- can’t accommodate Data Packet 
Length 
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Table 3 - SMDI Sense Codes (for use with REQUEST SENSE 
command) 


Af the 18. 
byte Extended Sense Data format. They are appropriate only when reporting one of the S 
error conditions listed below, and should be used only with a Sense Key (byte 2) value 


aie Additional Sense 
ie nes defined by the SCSI 


80H SEND rejected - slave rep 


81H RECEIVE rejected 


82H 
83H 
84H 
85H Es eed - initiator’s Transfer Length and Additional Message Length 
S are in conflict. 
86H END rejected - initiator’s Additional Message Length parameter is incorrect for 


the current message. 
ty 
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